1. Technical Field
The present disclosure generally relates to a method of a UEFI firmware and computer system thereof; particularly, the present disclosure relates to an method and computer system for executing a UEFI firmware, containing variables and instruction sets respectively for a plurality of different bootloader programs, for supporting pre-boot initialization of the different bootloader programs.
2. Description of the Related Art
Traditionally, computing systems may boot to only one operating system. The boot up of the operating system is typically handled by a low level instruction code that is used as an intermediary between the hardware components of the computing system and the operating software and other high level software executing on the computing system. This low level instruction code is often known as the Basic Input/Output System (“BIOS”) firmware and provides a set of software routines that allow high level software to interact with the hardware components of the computing system. The firmware performs routines for conducting Power-On Self Test (“POST”) each time the computing system is powered on in order to test and initiate all hardware components in the computing system before handing off control to the operating system. These hardware components may include the system main memory, disk drives, and keyboards.
However, as technology has progressed and many different computing systems and operating systems have sprung up, boot up firmwares based on the traditional BIOS standard, which was originally designed for personal computers of International Business Machine Corporation (IBM), have become a point of restriction or limitation as to what the Operating System may control with the hardware. As new hardware and software technologies were being developed, this source of restriction became a major obstacle in the hardware-software interaction. As a result, a new standard of BIOS firmware has been proposed and widely adopted by many major industry leaders. This new standard is called the Unified Extensible Firmware Interface (UEFI).
With the adoption of UEFI standards, BIOS companies were able to produce UEFI firmware for computing systems, while companies producing Operating Systems were able to take advantage of the services these UEFI firmware provided by producing UEFI compliant Operating Systems. However, UEFI requires the firmware and the operating system loader (or kernel) to be size-matched. For instance, a 64-bit UEFI firmware implementation can only load a 64-bit UEFI operating system boot loader or kernel. As a result, for a UEFI compliant computing system having computing architecture (such as x86_64) that can support different processor modes (processor instruction sets), separate boot up images (compiled firmwares) would be needed to address booting up to different operating systems of different processor modes. For example, to support the option of being able to boot into 32-bit or 64-bit Operating Systems on a x86_64 computing system, separate UEFI firmwares respectively addressing the 32-bit and 64-bit Operating Systems would need to be compiled and installed on the computing system. For computing systems with limited memory or limited physical space for memory by design, the added storage requirement for separate UEFI firmwares to be compiled to different boot up images would become a problem for those computing systems. In other cases where the UEFI firmware has already booted the computing system to a particular processor mode, although the operating system boot loader (or kernel) can change processor modes if it desires, runtime services will be bar from usage (unless the kernel switches back again). Therefore, there is a need to reduce the complexities that come from having multiple UEFI boot up firmware in order to support multiple UEFI compliant Operating Systems.